查看原文
其他

隐私计算距离互联互通还有很长的路要走|DataFun专家访谈

DataFun 大话数智 2024-01-09

隐私计算技术的相关产业落地尚处于初期阶段。当产业界持续地强调隐私计算将走向互联互通的时候,专家告诉DataFun,业界对隐私计算的认知还远未成熟,单个产品独自落地已经很困难,更不用提互联互通。无论是技术人员对算法理论的理解,还是用户对隐私计算类型产品的认知和接受度,以及法律对算法适用性的释义等,都有很多模糊地带,缺乏明晰的理论边界认识和量化评估方法。

本文整理自DataFun对阿里云Datatrust总架构师梁爱平的访谈,帮助读者理解隐私计算产品的应用现状和挑战


目前常见的隐私计算类产品的主要技术模块包含:数据源、隐私计算算法和系统管理。隐私计算的一般流程是从多方数据源获数据,然后,基于隐私计算算法进行联合分析或联合建模,支撑联合营销、联合风控、联合定价等上层应用。系统管理负责算法部署阶段,包括节点管理、集群管理、项目管理、数据管理、账号管理、区块链管理、任务管理、授权管理等。

在下文中,我们将依次按照隐私计算在数据源、隐私计算算法、系统管理、商业化产品落地等方面的现状给出一些总结,并在最后总结讨论未来趋势。


引言


DataFun社区|出品

数据智能专家访谈 第07期|来源




01



数据源:没有非常大的技术挑战


 
在隐私计算的数据源方面,由于每个用户都有各自的存储介质,通常不希望在应用隐私计算产品时再额外引入新的存储介质。

随着产品服务客户数量的增加,数据源适配的工作量也会随之增加,但其背后主要是因为需要大量的人力来保证实施,并没有非常大的技术挑战难题。所以数据源部分技术挑战相对比较低,且最容易统一。


02


隐私计算算法:理论与工程之间的鸿沟


对于隐私计算而言,很多企业直接奔着商业化目的而来,但对底层理论的投入参差不齐。不管是人力储备、资源投入、理论理解,不同企业之间的差距还是很大的。作为安全类的产品,如果企业对于数据安全这个最重要的产品卖点都无法深入理解,其实是一件很不合理的事情。

但现实情况是,很多技术人员都不完全清楚自己所采用的算法的正确性和适用范围。另外,即使是隐私计算的相关专业评测机构,也很难对安全算法本身进行专业的评测,主要还是因为他们自身对相关技术的理解有限。比如隐私计算中经常用到的椭圆曲线,很多不是密码学出身的人基本上不知道自己使用的算法库是否按照正确的理论实现了,对于密码学出身的人,虽然理解算法理论本身,但是因为工程知识的欠缺,也是大部分都看不懂一个具体的实现是否正确。

具体到隐私计算的工程落地方面,隐私计算的产品效果是否能够和理论声称的一致,开源库实现有没有留后门等等问题,其实都很难进行衡量和保证。举个例子,目前学术界的开源库对于椭圆曲线的实现,大概有80%的实现都有问题,或者根本就是错误的,然而工程开发人员和评测机构都很难明确和评估这样的信息。

对于当下的隐私计算产业界而言,隐私计算算法距离互联互通还有很长的路要走,尤其是算法理论层面的共识还需要行业的共同努力。

和理论层面的差距相比较,工程层面的协议安全性相对比较容易达成共识。比如对于某一个链路是否加密,以及使用的加密算法,已经有很多现有的工程标准,因此也比较容易达成工程落地。

当然工程层面对产品研发工程师,也有很多的知识需要弥补。比如在多方安全计算中,两方安全计算和多方安全计算的实现方式不同,哪些数据能传输,哪些数据不能传输,需要深入理解安全协议,需要工程师能够知晓理论;计算过程中,怎么定义哪些信息可泄漏,哪些信息不可以泄漏,需要工程师去理解业务;SQL分析计算过程中,每一个算子如何实现安全计算,以及这些实现怎么保证性能需要工程师掌握SQL的语法树。再到细粒度的层面,把SQL里面的每一个关系代数,每一个计算函数拆出来,都是一个种类的多方安全计算问题,以SQL中的Join为例,最直观的理解就是 Inner join = PSI ; Full join = PrivateId;Left join 和 Right join = Circuit PSI。

对于算法理论层面的缺陷,根本原因之一还是行业人才的匮乏。当然理解的鸿沟不仅存在于理论和工程之间,还存在于安全技术和法律之间。

很多时候对于具体的安全方案,其实并不一定要完全遵守严格的密码学要求,只需要根据当前特定的场景,能够解决当前场景的安全问题即可。此外,出于业务的性能考虑,很多安全方案会结合实际场景下信息泄露的量和信息泄露的概率,做一些安全降级,但法务很难理解这种降级会带来多大的影响。

但这又衍生出一个问题,法务人员对安全方面的知识积累和理解,限制了其评估能力。

在实际落地过程中,安全和性能之间进行折中是很正常的做法。但重点在于,要在做折中后,让评审方或数据提供方明白这种折中背后的风险有多大,或者让相关人员理解这种降级会带来多大程度的信息泄露,以及如何通过一些业务流程控制来规避这些安全问题,但是这在实际落地过程中也有很大难度。

最后,目前的法律法规在特定场景下安全性的定义,还要通过案例来完善。比如对于联邦学习,业界的一些开源库其实关注重点并不完全在安全方面,而更多在于联合机器学习方面。而在机器学习的梯度传递过程中,会涉及梯度传递是否泄露信息的安全问题(这个问题对于理论而也很难严格论证安全性)。也就是在实际测试中通过攻击来获取个人隐私的时候,难度也很高。也就是说,直接传递梯度方法的安全性不可被理论严格证明,但是具体泄漏了多大程度的信息量也不可以被量化。

总体而言,安全性证明、量化评估、场景适配性仍然是很大的问题,这原本是隐私计算最重要的问题,但是却很容易被大家忽视。 

总结一下,业界在行业共识方面还未形成健康的状态。以上现状都是由于隐私计算的理论研究和工程落地差距过大。隐私计算是近年才在业界受到重视并开始发展,无论是人才还是认知,业界的储备都还不够。当然,相信这种局面也会随着时间逐渐得到改善。


03


系统管理:互联互通的重灾区


系统管理本身的实现不复杂,但确实是互联互通中非常重要的流程。系统管理的互联互通标准是可以让企业证明系统管理流程合规的重要手段。

隐私计算系统的实现一般有两种模式,一种是点对点的模式,一种是中心化的公有云调度模式。特别是对于第二种模式,用户会关心系统管理或调度涉及到的信息,以及与本地的交互信息,是否会涉及到安全问题。换句话说,如何保证隐私计算查询的数据中不包括本地的密钥信息、数据库的连接信息等敏感信息,另外就是系统管理流程是否按照企业声称的流程进行。

不同隐私计算产品的互联互通也是系统管理的一大挑战,主要是因为每家企业的产品都有自己的特点。比如A产品是有项目实体的,但B产品没有;或者A产品的节点有个性化的信息而B产品没有。再比如用于识别节点身份信息的license ID或user ID不通等。互联互通甚至可以说是系统管理的重灾区,挑战性很大。以上这些都需要有标准来规范化。

此外系统管理中涉及上述问题的主要模块是授权管理和区块链管理。区块链本身不属于隐私计算,但它是用于解决隐私计算审计能力的技术。在授权管理和区块链管理中,会存在安全性证明问题,要想解决不同企业的安全产品之间的互联互通,有待更多的标准推广后,才能落地。


04


产品:四大能力要素


个人认为,隐私计算产品化需要特别关注四个方面的要素,首先是安全性,其次是产品本身的可扩展性、性能和成本,然后是产品的易用性,最后是部署形式和交付能力。

隐私计算商业化产品中最重要的权衡因素是安全、性能和成本。以常用的隐私集合求交即PSI算法为例,每一种PSI算法都有自己的特性,实际落地中会根据不同的因素,比如数据量级、客户端的算力、带宽等因素来选择不同的PSI算法。

假设在固定的计算资源下,以数据量级为例,如果参与方的数据量级比较接近,一般会选择稳定性好或可批量、分布式计算的PSI算法,比如DS PSI算法,其分布式实现比较容易,可以很快地在用户已有的Hadoop集群或者MaxCompute等商业服务集群上落地;但是如果数据量级差异比较大,会选用另一类PSI算法,其特性是在数据量小的一端,计算量也比较小,整体通信量也比较小,但在数据量比较大的一端,消耗的资源会比较多,比如基于OPRF、OT的PSI算法。基于上述方法,可以提高隐私计算的性能,同时降低成本。当然在选择算法的时候,算法必须是安全的,比如经过论文发表的算法可以认为是安全的。在这个前提下,企业尽量通过安全协议的复杂组合实现性能和成本的权衡。

当然还有一些算法,如果在应用中要实现理论安全性,会导致性能无法达到要求,比如基于全同态的隐匿信息查询、基于安全多方的任意SQL等。在多方安全计算的隐匿查询中,一般会通过一些额外的辅助来完成隐匿信息查询,这时就需要考虑安全性和性能的折中。

隐私计算产品的性能影响因素有很多。首先是底层理论的突破,比如对椭圆曲线的算法迭代是在持续进行的;其次是分布式能力,比如用户有一个Hadoop集群,可以通过UDF的方式完成Hadoop集群上的计算,相当于把计算的过程插件化到用户已有的集群上,如果用户没有大规模的计算集群,则企业可以通过容器化的集群方式实现分布式能力,是否具备深刻理解协议并把协议分布式化的能力,是能否提高性能的一个重要指标;最后是通信优化、硬件加速等方法

对于隐私计算产品的用户,经常会遇到选择标准和企业关注指标不匹配的情况,比如性能、数据质量、安全性等方面,企业和用户所重视的方面是有差别的。通常来说,用户最看重的还是数据因素,其会认为合适的数据带来的提升会远大于隐私计算平台的重要性,主要是考虑到有了好的数据,后续的调优空间会更大。

关于交付的部分,作为一种 B 端用户交互的场景,用户对B 端交付的产品要求都特别多:既要便宜,又要稳定,又要安全,还要易用性高。这本来就很难,再加上是 b 端和 b 端交互,而且这两个 b 端都不是企业能控制的,企业甚至都不了解他们的网络环境,还要让他们完成交互。所以这其实才是最大的难题,即怎么控制自己不可控的两个网络之间完成一次计算,且它是满足安全理论定义的,难点在于架构设计如何支撑不同环境下的通信。换句话说,交付过程中的不确定性和用户的高要求是很大的难点。

虽然在商业化过程中,有很多问题,但是隐私计算最大的应用挑战,还是在于是否正确地使用算法,即按照法规,哪些算法可以在哪些场景中明确地使用,带来明确的安全性。而全栈部署、互联互通、实时预测等方面,并不属于核心挑战,更偏向商业化成本问题,只要有足够的商业驱动力,相信这些问题最终都可以得到解决。


05


前沿与趋势:互联互通和分布式计算最重要


对于隐私计算的未来发展,个人预计行业会走向多产品跨平台的互联互通、安全协议分布式化、软硬件结合、以及一体机的方向发展。在这里面互联互通和大规模分布式计算的重要性最高。而前者的成熟度还很低,对于后者,已有不少算法实现了分布式,但其并不存在根本的挑战,更偏向于工作量问题——就是通过不停的积累,把所有的算法都分布式化。

对于一体机已有许多企业在落地,但对于其意义和目的,行业其实没有很明确的共识,因此还不算成熟。

对于软硬件的结合,近期很多企业开始关注这个方向。这是一个很有潜力的方向,但是问题在于硬件的突破没有那么快。而且,可信硬件的编码学习成本比较高,基于可信硬件的中间层质量也是参差不齐。

- End -
访谈人:梁爱平
与谈人:刘晓坤 DataFun

撰文:刘晓坤 DataFun



▌专家介绍

👨 梁爱平

阿里云Datatrust总架构师,十年左右大数据平台和数据安全相关经验,目前主要负责Datatrust架构设计和开发,完成了Datatrust本地计算引擎、双层调度、安全多方协议编译器等隐私计算平台重要模块的架构和实现。

据智能专家访谈

“数据智能专家访谈”是 DataFun 新推出的内容系列,本系列旨在访谈不同公司的核心技术人员,得到专家在不同领域的洞察,包括但不限于行业重点、热点、难点,增加读者对行业技术的了解。

▌大话数智

大话数智,是DataFun策划的智库类公众号,包括但不限于知识地图、深度访谈、直播、课程等学习资料,旨在为广大数据智能从业者、数据智能团队提供一个日常学习成长的平台,促进先进的数据智能技术的传播与广泛落地。

继续滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存